Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.224

Text File | 1996-02-12 | 28KB | 698 lines

Frequently Asked Questions (FAQS);faqs.224


Section 13. Lint

13.1:    I just typed in this program, and it's acting strangely.  Can
    you see anything wrong with it?

A:    Try running lint first (perhaps with the -a, -c, -h, -p and/or
    other options).  Many C compilers are really only half-
    compilers, electing not to diagnose numerous source code
    difficulties which would not actively preclude code generation.

13.2:    How can I shut off the "warning: possible pointer alignment
    problem" message lint gives me for each call to malloc?

A:    The problem is that traditional versions of lint do not know,
    and cannot be told, that malloc "returns a pointer to space
    suitably aligned for storage of any type of object."  It is
    possible to provide a pseudoimplementation of malloc, using a
    #define inside of #ifdef lint, which effectively shuts this
    warning off, but a simpleminded #definition will also suppress
    meaningful messages about truly incorrect invocations.  It may
    be easier simply to ignore the message, perhaps in an automated
    way with grep -v.

13.3:    Where can I get an ANSI-compatible lint?

A:    A product called FlexeLint is available (in "shrouded source
    form," for compilation on 'most any system) from

        Gimpel Software
        3207 Hogarth Lane
        Collegeville, PA  19426  USA
        ([phone]

    The System V release 4 lint is ANSI-compatible, and is available
    separately (bundled with other C tools) from Unix Support Labs
    (a subsidiary of AT&T), or from System V resellers.


Section 14. Style

14.1:    Here's a neat trick:

        if(!strcmp(s1, s2))

    Is this good style?

A:    Perhaps; perhaps not.  The test succeeds if the two strings are
    equal, but its form suggests that it tests for inequality.

    Another solution is to use a macro:

        #define Streq(s1, s2) (strcmp((s1), (s2)) == 0)

    Opinions on code style, like those on religion, can be debated
    endlessly.  Though good style is a worthy goal, and can usually
    be recognized, it cannot be codified.

14.2:    What's the best style for code layout in C?

A:    K&R, while providing the example most often copied, also supply
    a good excuse for avoiding it:

        The position of braces is less important,
        although people hold passionate beliefs.
        We have chosen one of several popular styles.
        Pick a style that suits you, then use it
        consistently.

    It is more important that the layout chosen be consistent (with
    itself, and with nearby or common code) than that it be
    "perfect."  If your coding environment (i.e. local custom or
    company policy) does not suggest a style, and you don't feel
    like inventing your own, just copy K&R.  (The tradeoffs between
    various indenting and brace placement options can be
    exhaustively and minutely examined, but don't warrant repetition
    here.  See also the Indian Hill Style Guide.)

    The elusive quality of "good style" involves much more than mere
    code layout details; don't spend time on formatting to the
    exclusion of more substantive code quality issues.

    Reference: K&R Sec. 1.2 p. 10.

14.3:    Where can I get the "Indian Hill Style Guide" and other coding
    standards?

A:    Various documents are available for anonymous ftp from:

        Site:            File or directory:

        cs.washington.edu    ~ftp/pub/cstyle.tar.Z
        (128.95.1.4)        (the updated Indian Hill guide)

        cs.toronto.edu        doc/programming

        giza.cis.ohio-state.edu    pub/style-guide


Section 15. Floating Point

15.1:    My floating-point calculations are acting strangely and giving
    me different answers on different machines.

A:    First, make sure that you have #included <math.h>, and correctly
    declared other functions returning double.

    If the problem isn't that simple, recall that most digital
    computers use floating-point formats which provide a close but
    by no means exact simulation of real number arithmetic.
    Underflow, cumulative precision loss, and other anomalies are
    often troublesome.

    Don't assume that floating-point results will be exact, and
    especially don't assume that floating-point values can be
    compared for equality.  (Don't throw haphazard "fuzz factors"
    in, either.)

    These problems are no worse for C than they are for any other
    computer language.  Floating-point semantics are usually defined
    as "however the processor does them;" otherwise a compiler for a
    machine without the "right" model would have to do prohibitively
    expensive emulations.

    This article cannot begin to list the pitfalls associated with,
    and workarounds appropriate for, floating-point work.  A good
    programming text should cover the basics.

    References: EoPS Sec. 6 pp. 115-8.

15.2:    I'm trying to do some simple trig, and I am #including <math.h>,
    but I keep getting "undefined: _sin" compilation errors.

A:    Make sure you're linking against the correct math library.  For
    instance, under Unix, you usually need to use the -lm option at
    the end of the command line when compiling/linking.

15.3:    Why doesn't C have an exponentiation operator?

A:    You can #include <math.h> and use the pow() function, although
    explicit multiplication is often better for small positive
    integral exponents.

    References: ANSI Sec. 4.5.5.1 .

15.4:    I'm having trouble with a Turbo C program which crashes and says
    something like "floating point formats not linked."

A:    Some compilers for small machines, including Turbo C (and
    Ritchie's original PDP-11 compiler), leave out floating point
    support if it looks like it will not be needed.  In particular,
    the non-floating-point versions of printf and scanf save space
    by not including code to handle %e, %f, and %g.  It happens that
    Turbo C's heuristics for determining whether the program uses
    floating point are insufficient, and the programmer must
    sometimes insert a dummy explicit floating-point call to force
    loading of floating-point support.


Section 16. System Dependencies

16.1:    How can I read a single character from the keyboard without
    waiting for a newline?

A:    Contrary to popular belief and many people's wishes, this is not
    a C-related question.  (Nor are closely-related questions
    concerning the echo of keyboard input.)  The delivery of
    characters from a "keyboard" to a C program is a function of the
    operating system in use, and has not been standardized by the C
    language.  Some versions of curses have a cbreak() function
    which does what you want.  Under UNIX, use ioctl to play with
    the terminal driver modes (CBREAK or RAW under "classic"
    versions; ICANON, c_cc[VMIN] and c_cc[VTIME] under System V or
    Posix systems).  Under MS-DOS, use getch().  Under VMS, try the
    Screen Management (SMG$) routines.  Under other operating
    systems, you're on your own.  Beware that some operating systems
    make this sort of thing impossible, because character collection
    into input lines is done by peripheral processors not under
    direct control of the CPU running your program.

    Operating system specific questions are not appropriate for
    comp.lang.c .  Many common questions are answered in
    frequently-asked questions postings in such groups as
    comp.unix.questions and comp.os.msdos.programmer .  Note that
    the answers are often not unique even across different variants
    of a system; bear in mind when answering system-specific
    questions that the answer that applies to your system may not
    apply to everyone else's.

    References: PCS Sec. 10 pp. 128-9, Sec. 10.1 pp. 130-1.

16.2:    How can I find out if there are characters available for reading
    (and if so, how many)?  Alternatively, how can I do a read that
    will not block if there are no characters available?

A:    These, too, are entirely operating-system-specific.  Some
    versions of curses have a nodelay() function.  Depending on your
    system, you may also be able to use "nonblocking I/O", or a
    system call named "select", or the FIONREAD ioctl, or kbhit(),
    or rdchk(), or the O_NDELAY option to open() or fcntl().

16.3:    How can I clear the screen?  How can I print things in inverse
    video?

A:    Such things depend on the terminal type (or display) you're
    using.  You will have to use a library such as termcap or
    curses, or some system-specific routines, to perform these
    functions.

16.4:    How do I read the mouse?

A:    Consult your system documentation, or ask on an appropriate
    system-specific newsgroup (but check its FAQ list first).  Mouse
    handling is completely different under the X window system than
    it is under MS-DOS than it is on the Macintosh.

16.5:    How can my program discover the complete pathname to the
    executable file from which it was invoked?

A:    argv[0] may contain all or part of the pathname, or it may
    contain nothing.  You may be able to duplicate the command
    language interpreter's search path logic to locate the
    executable if the name in argv[0] is present but incomplete.
    However, there is no guaranteed or portable solution.

16.6:    How can a process change an environment variable in its caller?

A:    In general, it cannot.  Different operating systems implement
    name/value functionality similar to the Unix environment in
    different ways.  Whether the "environment" can be usefully
    altered by a running program, and if so, how, is system-
    dependent.

    Under Unix, a process can modify its own environment (some
    systems provide setenv() and/or putenv() functions to do this),
    and the modified environment is usually passed on to any child
    processes, but it is _not_ propagated back to the parent
    process.

16.7:    How can I find out the size of a file, prior to reading it in?

A:    If the "size of a file" is the number of characters you'll be
    able to read from it in C, it is in general impossible to
    determine this number in advance.  Under Unix, the stat()
    function will give you an exact answer, and several other
    systems supply a Unix-like stat() which will give an approximate
    answer.  You can fseek to the end and then use ftell, but this
    usage is nonportable (it gives you an accurate answer only under
    Unix, and a guaranteed, but potentially approximate answer only
    for ANSI C "binary" files).

    Are you sure you have to determine the file's size in advance?
    Since the most accurate way of determining the size of a file as
    a C program will see it is to open the file and read it, perhaps
    you can rearrange the code to learn the size as it reads.

16.8:    How can a file be shortened in-place without completely clearing
    or rewriting it?

A:    BSD systems provide ftruncate(), several others supply chsize(),
    and a few may provide a (possibly undocumented) fcntl option
    F_FREESP.  Under MS-DOS, you can sometimes use
    write(fd, "x", 0).  However, there is no truly portable
    solution.

16.9:    How can I implement a delay, or time a user's response, with
    sub-second resolution?

A:    Unfortunately, there is no portable way.  V7 Unix, and derived
    systems, provided a fairly useful ftime() routine with
    resolution up to a millisecond, but it has disappeared from
    System V and Posix.

16.10:    How can I read in an object file and jump to routines in it?

A:    You want a dynamic linker and/or loader.  It is possible to
    malloc some space and read in object files, but you have to know
    an awful lot about object file formats, relocation, etc.  Under
    BSD Unix, you could use system() and ld -A to do the linking for
    you.  There is also a GNU package called "dld" which takes care
    of some or all of this.  See also question 7.5.


Section 17. Miscellaneous

17.1:    What can I safely assume about the initial values of variables
    which are not explicitly initialized?  If global variables start
    out as "zero," is that good enough for null pointers and
    floating-point zeroes?

A:    Variables with "static" duration (that is, those declared
    outside of functions, and those declared with the storage class
    static), are guaranteed initialized to zero, as if the
    programmer had typed "= 0".  Therefore, such variables are
    initialized to the null pointer (of the correct type) if they
    are pointers, and to 0.0 if they are floating-point.

    Variables with "automatic" duration (i.e. local variables
    without the static storage class) start out containing garbage,
    unless they are explicitly initialized.  Nothing useful can be
    predicted about the garbage.

    Dynamically-allocated memory obtained with malloc and realloc is
    also likely to contain garbage, and must be initialized by the
    calling program, as appropriate.  Memory obtained with calloc
    contains all-bits-0, but this is not necessarily useful for
    pointer or floating-point values (see question 3.9, and section
    1).

17.2:    How can I write data files which can be read on other machines
    with different word size, byte order, or floating point formats?

A:    The best solution is to use text files (usually ASCII), written
    with fprintf and read with fscanf or the like.  (Similar advice
    also applies to network protocols.)  Be skeptical of arguments
    which imply that text files are too big, or that reading and
    writing them is too slow.  Not only is their efficiency
    frequently acceptable in practice, but the advantages of being
    able to manipulate them with standard tools can be overwhelming.

    If you must use a binary format, you can improve portability,
    and perhaps take advantage of prewritten I/O libraries, by
    making use of standardized formats such as Sun's XDR (RFC 1014),
    OSI's ASN.1, CCITT's X.409, or ISO 8825 "Basic Encoding Rules."
    See also question 9.10.

17.3:    How can I return several values from a function?

A:    Either pass pointers to locations which the function can fill
    in, or have the function return a structure containing the
    desired values.  See also questions 2.12, 3.4, and 9.2.

17.4:    If I have a char * variable pointing to the name of a function
    as a string, how can I call that function?

A:    The most straightforward thing to do is maintain a
    correspondence table of names and function pointers:

        int function1(), function2();

        struct {char *name; int (*funcptr)(); } symtab[] =
            {
            "function1",    function1,
            "function2",    function2,
            };

    Then, just search the table for the name, and call through the
    associated function pointer.

17.5:    I seem to be missing the system header file <sgtty.h>.  Can
    someone send me a copy?

A:    Standard headers exist in part so that definitions appropriate
    to your compiler, operating system, and processor can be
    supplied.  You cannot just pick up a copy of someone else's
    header file and expect it to work, unless that person is using
    exactly the same environment.  Ask your compiler vendor why the
    file was not provided (or to send a replacement copy).

17.6:    How can I call FORTRAN (C++, BASIC, Pascal, Ada, LISP) functions
    from C?  (And vice versa?)

A:    The answer is entirely dependent on the machine and the specific
    calling sequences of the various compilers in use, and may not
    be possible at all.  Read your compiler documentation very
    carefully; sometimes there is a "mixed-language programming
    guide," although the techniques for passing arguments and
    ensuring correct run-time startup are often arcane.

    cfortran.h, a C header file, simplifies C/FORTRAN interfacing on
    many popular machines.  It is available via anonymous ftp from
    zebra.desy.de (131.169.2.244).

    In C++, a "C" modifier in an external function declaration
    indicates that the function is to be called using C calling
    conventions.

17.7:    Does anyone know of a program for converting Pascal or FORTRAN
    (or LISP, Ada, AWK, "Old" C, ...) to C?

A:    Several public-domain programs are available:

    p2c    written by Dave Gillespie, and posted to
        comp.sources.unix in March, 1990 (Volume 21); also
        available by anonymous ftp from csvax.cs.caltech.edu,
        file pub/p2c-1.20.tar.Z .

    ptoc    another comp.sources.unix contribution, this one written
        in Pascal (comp.sources.unix, Volume 10, also patches in
        Volume 13?).

    f2c    jointly developed by people from Bell Labs, Bellcore,
        and Carnegie Mellon.  To find about f2c, send the mail
        message "send index from f2c" to [e-mail]
        or research!netlib.  (It is also available via anonymous
        ftp on research.att.com, in directory dist/f2c.)

    This FAQ list's maintainer also has available a list of other
    commercial translation products, and some for more obscure
    languages.

    See also question 5.3.

17.8:    Where can I get copies of all these public-domain programs?

A:    If you have access to Usenet, see the regular postings in the
    comp.sources.unix and comp.sources.misc newsgroups, which
    describe, in some detail, the archiving policies and how to
    retrieve copies.  The usual approach is to use anonymous ftp
    and/or uucp from a central, public-spirited site, such as uunet
    (ftp.uu.net, 192.48.96.9).  However, this article cannot track
    or list all of the available archive sites and how to access
    them.  The comp.archives newsgroup contains numerous
    announcements of anonymous ftp availability of various items.
    The "archie" mailserver can tell you which anonymous ftp sites
    have which packages; send the mail message "help" to
    [e-mail] for information.  Finally, the
    newsgroup comp.sources.wanted is generally a more appropriate
    place to post queries for source availability, but check _its_
    FAQ list, "How to find sources," before posting there.

17.9:    When will the next International Obfuscated C Code Contest
    (IOCCC) be held?  How can I get a copy of the current and
    previous winning entries?

A:    The contest typically runs from early March through mid-May.  To
    obtain a current copy of the rules and other information, send
    e-mail with the Subject: line "send rules" to:

        {apple,pyramid,sun,uunet}!hoptoad!obfuscate  or
        [e-mail]

    Contest winners are first announced at the Summer Usenix
    Conference in mid-June, and posted to the net in July.  Previous
    winners are available on uunet (see question 17.8) under the
    directory ~/pub/ioccc.

17.10:    Why don't C comments nest?  Are they legal inside quoted
    strings?

A:    Nested comments would cause more harm than good, mostly because
    of the possibility of accidentally leaving comments unclosed by
    including the characters "/*" within them.  For this reason, it
    is usually better to "comment out" large sections of code, which
    might contain comments, with #ifdef or #if 0 (but see question
    5.7).

    The character sequences /* and */ are not special within
    double-quoted strings, and do not therefore introduce comments,
    because a program (particularly one which is generating C code
    as output) might want to print them.

    References: ANSI Appendix E p. 198, Rationale Sec. 3.1.9 p. 33.

17.11:    How can I implement sets and/or arrays of bits?

A:    Use arrays of char or int, with a few macros to access the right
    bit at the right index (try using 8 for CHAR_BIT if you don't
    have <limits.h>):

        #include <limits.h>        /* for CHAR_BIT */

        #define BITMASK(bit) (1 << ((bit) % CHAR_BIT))
        #define BITSLOT(bit) ((bit) / CHAR_BIT)
        #define BITSET(ary, bit) ((ary)[BITSLOT(bit)] |= BITMASK(bit))
        #define BITTEST(ary, bit) ((ary)[BITSLOT(bit)] & BITMASK(bit))

17.12:    What is the most efficient way to count the number of bits which
    are set in a value?

A:    This and many other similar bit-twiddling problems can often be
    sped up and streamlined using lookup tables (but see the next
    question).

17.13:    How can I make this code more efficient?

A:    Efficiency, though a favorite comp.lang.c topic, is not
    important nearly as often as people tend to think it is.  Most
    of the code in most programs is not time-critical.  When code is
    not time-critical, it is far more important that it be written
    clearly and portably than that it be written maximally
    efficiently.  (Remember that computers are very, very fast, and
    that even "inefficient" code can run without apparent delay.)

    It is notoriously difficult to predict what the "hot spots" in a
    program will be.  When efficiency is a concern, it is important
    to use profiling software to determine which parts of the
    program deserve attention.  Often, actual computation time is
    swamped by peripheral tasks such as I/O and memory allocation,
    which can be sped up by using buffering and cacheing techniques.

    For the small fraction of code that is time-critical, it is
    vital to pick a good algorithm; it is less important to
    "microoptimize" the coding details.  Many of the "efficient
    coding tricks" which are frequently suggested (e.g. substituting
    shift operators for multiplication by powers of two) are
    performed automatically by even simpleminded compilers.
    Heavyhanded "optimization" attempts can make code so bulky that
    performance is degraded.

    For more discussion of efficiency tradeoffs, as well as good
    advice on how to increase efficiency when it is important, see
    chapter 7 of Kernighan and Plauger's The Elements of Programming
    Style, and Jon Bentley's Writing Efficient Programs.

17.14:    Are pointers really faster than arrays?  How much do function
    calls slow things down?  Is ++i faster than i = i + 1?

A:    Precise answers to these and many similar questions depend of
    course on the processor and compiler in use.  If you simply must
    know, you'll have to time test programs carefully.  (Often the
    differences are so slight that hundreds of thousands of
    iterations are required even to see them.  Check the compiler's
    assembly language output, if available, to see if two purported
    alternatives aren't compiled identically.)

    It is "usually" faster to march through large arrays with
    pointers rather than array subscripts, but for some processors
    the reverse is true.

    Function calls, though obviously incrementally slower than in-
    line code, contribute so much to modularity and code clarity
    that there is rarely good reason to avoid them.

    Before rearranging expressions such as i = i + 1, remember that
    you are dealing with a C compiler, not a keystroke-programmable
    calculator.  Any decent compiler will generate identical code
    for ++i, i += 1, and i = i + 1.  The reasons for using ++i or
    i += 1 over i = i + 1 have to do with style, not efficiency.
    (See also question 4.4.)

17.15:    This program crashes before it even runs!  (When single-stepping
    with a debugger, it dies before the first statement in main.)

A:    You probably have one or more very large (kilobyte or more)
    local arrays.  Many systems have fixed-size stacks, and those
    which perform dynamic stack allocation automatically (e.g. Unix)
    can be confused when the stack tries to grow by a huge chunk all
    at once.

    It is often better to declare large arrays with static duration
    (unless of course you need a fresh set with each recursive
    call).

    (See also question 9.4.)

17.16:    What do "Segmentation violation" and "Bus error" mean?

A:    These generally mean that your program tried to access memory it
    shouldn't have, invariably as a result of improper pointer use,
    often involving malloc.

17.17:    Does anyone have a C compiler test suite I can use?

A:    Plum Hall (1 Spruce Ave., Cardiff, NJ 08232, USA), among others,
    sells one.

17.18:    Where can I get a YACC grammar for C?

A:    The definitive grammar is of course the one in the ANSI
    standard.  Several copies are floating around; keep your eyes
    open.  There is one on uunet (see question 17.8) in
    usenet/net.sources/ansi.c.grammar.Z (including a companion
    lexer).  The FSF's GNU C compiler contains a grammar, as does
    the appendix to K&R II.

    References: ANSI Sec. A.2 .

17.19:    How do you pronounce "char"?

A:    You can pronounce the C keyword "char" in at least three ways:
    like the English words "char," "care," or "car;" the choice is
    arbitrary.

17.20:    What's a good book for learning C?

A:    Mitch Wright maintains an annotated bibliography of C and Unix
    books; it is available for anonymous ftp from ftp.rahul.net in
    directory pub/mitch/YABL.

    This FAQ list's editor maintains a collection of previous
    answers to this question, which is available upon request.

17.21:    Where can I get extra copies of this list?  What about back
    issues?

A:    For now, just pull it off the net; it is normally posted to
    comp.lang.c on the first of each month, with an Expiration: line
    which should keep it around all month.  It can also be found in
    the newsgroup news.answers .  Several sites archive news.answers
    postings and other FAQ lists, including this one; the archie
    server (see question 17.8) should help you find them.  See the
    meta-FAQ list in news.answers for more information.

    This list is an evolving document, not just a collection of this
    month's interesting questions.  Older copies are obsolete and
    don't contain much, except the occasional typo, that the current
    list doesn't.


Bibliography

ANSI    American National Standard for Information Systems --
    Programming Language -- C, ANSI X3.159-1989 (see question 5.2).

JLB    Jon Louis Bentley, Writing Efficient Programs, Prentice-Hall,
    1982, ISBN 0-13-970244-X.

H&S    Samuel P. Harbison and Guy L. Steele, C: A Reference Manual,
    Second Edition, Prentice-Hall, 1987, ISBN 0-13-109802-0.
    (A third edition has recently been released.)

PCS    Mark R. Horton, Portable C Software, Prentice Hall, 1990,
    ISBN 0-13-868050-7.

EoPS    Brian W. Kernighan and P.J. Plauger, The Elements of Programming
    Style, Second Edition, McGraw-Hill, 1978, ISBN 0-07-034207-5.

K&R I    Brian W. Kernighan and Dennis M. Ritchie, The C Programming
    Language, Prentice Hall, 1978, ISBN 0-13-110163-3.

K&R II    Brian W. Kernighan and Dennis M. Ritchie, The C Programming
    Language, Second Edition, Prentice Hall, 1988, ISBN 0-13-
    110362-8, 0-13-110370-9.

Knuth    Donald E. Knuth, The Art of Computer Programming, (3 vols.),
    Addison Wesley, 1981.

CT&P    Andrew Koenig, C Traps and Pitfalls, Addison-Wesley, 1989,
    ISBN 0-201-17928-8.

    P.J. Plauger, The Standard C Library, Prentice Hall, 1992,
    ISBN 0-13-131509-9.

    Harry Rabinowitz and Chaim Schaap, Portable C, Prentice-Hall,
    1990, ISBN 0-13-685967-4.

There is a more extensive bibliography in the revised Indian Hill style
guide (see question 14.3).  See also question 17.20.


Acknowledgements

Thanks to Jamshid Afshar, Sudheer Apte, Dan Bernstein, Stan Brown, Joe
Buehler, Burkhard Burow, D'Arcy J.M. Cain, Raymond Chen, Christopher
Calabrese, James Davies, Norm Diamond, Ray Dunn, Stephen M. Dunn, Bjorn
Engsig, Dave Gillespie, Samuel Goldstein, Alasdair Grant, Ron Guilmette,
Doug Gwyn, Tony Hansen, Joe Harrington, Guy Harris, Jos Horsmeier, Blair
Houghton, Kirk Johnson, Peter Klausler, Andrew Koenig, Tom Koenig, John
Lauro, Don Libes, Christopher Lott, Tim McDaniel, Evan Manning, Barry
Margolin, Mark Moraes, Darren Morby, Richard A. O'Keefe, Hans Olsson,
Francois Pinard, randall@virginia, Pat Rankin, Rich Salz, Chip
Salzenberg, Paul Sand, Doug Schmidt, Patricia Shanahan, Peter da Silva,
Joshua Simons, Henry Spencer, Erik Talvola, Clarke Thatcher, Chris
Torek, Goran Uddeborg, Wietse Venema, Ed Vielmetti, Larry Virden, Freek
Wiedijk, and Dave Wolverton, who have contributed, directly or
indirectly, to this article.  Special thanks to Karl Heuer, and
particularly to Mark Brader, who (to borrow a line from Steve Johnson)
have goaded me beyond my inclination, and occasionally beyond my
endurance, in relentless pursuit of a better FAQ list.


                    Steve Summit
                    [e-mail]
                    [e-mail]
                    mit-eddie!adam.mit.edu!scs

This article is Copyright 1988, 1990-1992 by Steve Summit.
It may be freely redistributed so long as the author's name, and this
notice, are retained.
The C code in this article (vstrcat(), error(), etc.) is public domain
and may be used without restriction.
Xref: bloom-picayune.mit.edu rec.arts.disney:11446 news.answers:4726
Path: bloom-picayune.mit.edu!enterpoop.mit.edu!mojo.eng.umd.edu!darwin.sura.net!mlb.semi.harris.com!uflorida!purdue!haven.umd.edu!uunet!seismo!tanida
From: [e-mail] (Tom Tanida)
Newsgroups: rec.arts.disney,news.answers
Subject: rec.arts.disney FAQ, part 1a
Summary: FAQ for rec.arts.disney
Keywords: FAQ, disney
Message-ID: <[e-mail]>
Date: 16 Dec 92 22:44:36 GMT
Expires: 16 Dec 92 22:44:36 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Tom Tanida)
Followup-To: rec.arts.disney
Lines: 645
Approved: [e-mail]
Nntp-Posting-Host: beno.css.gov
Originator: [e-mail]

Archive-name: disney-faq/part1a
Last-modified: 16 Dec 1992

Frequently Asked Questions List For rec.arts.disney, part 1
Version 1.4, last revised 12/16/92